The technology disclosed addresses initiation of peer-to-peer media exchange sessions, with traversal of NAT and firewall devices, in a manner adapted to roaming. In particular, it involves preliminary determination of NAT/firewall topology, which reduces latency at initiation, and hole punching technologies to select a routing and traversal strategy that reduces reliance on external media relay devices.
Communicating media over IP is a versatile and cheap option. It is versatile because personal computers, set-top boxes and similar computing devices have screen and processing resources that plain old telephone system (POTS) handsets do not. In this sense, cell phones are small computing devices that have pre-configured feature sets or may be user upgradeable (especially cell phones that run the Palm or Microsoft CE operating systems.) Communication over IP is cheaper and faster than incumbent POTS networks. The realities of versatility and low price have propelled voice over IP (VOIP) to the forefront, along with video and multimedia delivery over IP.
Mobile VOIP is typically thought of as wireless, although hotels often provide wired connections that are privately managed, in addition to wireless. Roaming users with mobile VOIP devices almost immediately confront privately managed, legacy network devices, including NAT and firewall devices, which are designed to thwart the traffic patterns that support peer-to-peer connection over IP. Some firewall devices block unreliable transport protocols, including UDP packets, which are the preferred transport for media delivery. Firewalls typically block session initiation requests from outside sources. Essentially, firewalls block incoming calls. Attempts of outsiders to open sessions are thwarted by NAT devices, which are otherwise intended to share limited IP address space. NAT devices, in concept, share one or a few IP addresses and multiple port numbers among many intranet users who have non-routable IP addresses and may all be seeking to use the same port number. Internal IP addresses and port numbers are mapped to NAT-assigned external IP addresses and port numbers (“IP/port addresses”). NAT devices, in practice, obscure the port number that will be assigned to a particular intranet user. Some styles of NAT devices, such as the so-called full cone NAT's, allocate external port numbers to intranet users in a predictable fashion. Other styles of NAT devices, such as the so-called symmetric NAT, allocate external ports in a pattern that is unpredictable to any particular intranet user. The combination of privately managed, legacy network NAT and firewall devices presents a substantial challenge for a roaming user.
NAT and firewall traversal present issues that attracted much attention and a series of methodology proposals from the Internet Society's Internet Engineering Task Force (IETF). The many specifications produced by the IETF for traversal of NAT include STUN, ICE, rport, symmetric RTP, TURN, SIP Outbound, SDP attribute for RTCP, and others. An overall discussion of work by IETF is found in C. Boulton, Ed., J Rosenberg, G. Camarillo, “Best Current Practices for NAT Traversal for SIP”, draft-ietf-sipping-nat-scenarios-05 (Jun. 26, 2006), viewed at http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-05.txt on Sep. 30, 2006. The best current practices document identifies itself as giving the overall context for how NAT traversal efforts should utilize the IETF specifications. Id. at 3, section 1.
Early traversal proposals included J. Rosenberg et al., “STUN—Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)” RFC 3489 (March 2003) viewed at http://www.ietf.org/rfc/rfc3489.txt?number=3489 on Sep. 30, 2006, and “Traversal Using Relay NAT (TURN)”, draft-rosenberg-midcom-turn-08 (Sep. 9, 2005) viewed at http://tools.ietf.org/html/draft-rosenberg-midcom-turn-08 on Sep. 30, 2006, which evolved into “Obtaining Relay Addresses from Simple Traversal of UDP Through NAT (STUN)” draft-ietf-behav-turn-01 (February 2006) viewed at http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-01.txt on Sep. 30, 2006. An early consolidation of traversal proposals appeared as J. Rosenberg, “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for the Session Initiation Protocol (SIP)”, draft-rosenberg-sipping-ice-01 (Jun. 30, 2003) viewed at http://tools.ietf.org/html/draft-rosenberg-sipping-ice-01 on Sep. 30, 2006.
The STUN protocol defines a special STUN server in the public address space to return to a STUN client in a private address space information including the public NAT IP address and port being used for a particular session. This proved useful with full cone NAT devices, but not with symmetrical NAT devices. Deficiencies in STUN lead to the TURN protocol proposal, which was designed to solve the media traversal issue for symmetric NATs. TURN relies on a server that is inserted in the media and signaling path, such as in the customer's DMZ or as part of the service provider's network. This server sits outside the firewall and NAT, exposed to incoming calls. This protocol is viewed by some as having serious security implications, as being deficient in support for quality of service (QOS) measures and adding significant complexity to SIP installations.
The ICE protocol builds upon STUN and TURN, producing a very complicated approach. The cumbersomeness of ICE can be seen in “Best Current Practices for NAT Traversal for SIP”, supra, section 4.2.1 at pp. 30-40. A single example of implementing the ICE protocol requires 10 pages to diagram and explain. In addition to the latency apparent from the complex messaging diagrams, analysis of ICE reveals that cooperation of firewalls and alteration of the SIP messages protocol, including modifying message flows, are envisioned by ICE. This makes ICE impractical for many users to implement and cumbersome, at best.
Accordingly, an opportunity arises to introduce new architectures and protocols for mobile VOIP and mobile media over IP users. Faster protocols that are relatively easy to implement and generally compatible with incumbent network devices can result.